• при дизайне систем самые сложные вопросы появляются с хранением данных
• хранение данных
  • данные храним в разных местах
    • в памяти приложений
    • в очередях (почти базы данных)
    • в базах данных
      • SQL
      • No SQL
      • New SQL
      • Key-Value
      • полнотекстовые
      • In Memory
      • Очереди
      • Графовые (в т.ч. триплы)
      • Объектные
      • Иерархические
    • чем отличаются?
      • модель данных
        • документы
        • таблицы
        • графы
        • иерархические
      • данные могут быть со схемой и без
      • языки запросов
        • отношения
        • поиск
        • модификация
        • примеры
          • SQL
          • MapReduce
          • SPARQL, Cypher
          • Получение данных по ключу
          • Варианты фильтрации и поиска
      • хранят в памяти или на дисках
      • индексы
        • hash
        • sstable
        • b-tree
        • полнотекстовый и неточный индекс
      • локальность данных
        • строковые и документные
        • колоночные
      • безопасность данных
        • бекапы
        • репликация
      • горизонтальная масштабируемость (шардирование)
      • поведение при недоступности части нод, если можно сделать несколько нод
  • вопрос синхронизации
    • временные данные (кто взял обработку этого запроса?)
• SQL — язык и базы
• Индексы и быстрый доступ к данным
• ACID
• распределенные SQL

TODO: добавить по OLAP/OLTP TODO: еще добавить про то, что базы данных могут быть оптимизированы под чтение или под запись с редким чтением TODO: каталог в библиотеке, как аналог SSTable

Хранение данных в информационных системах

Мы начинаем рассматривать архитектуры систем и их эволюцию. Традиционно в прошлом системы часто строились без состояния. Большая часть приложений разрабатывалась как бекенды без состояния, распределенные за балансировщиком нагрузки и работающие с единственным SQL сервером. Однако с усложнением систем и повышением нагрузки этот подход стал неприеменимым — в основном из-за того, что единственный SQL перестал справляться с типичной нагрузкой.

Решением проблемы сначала стало использование многих типов баз данных — каждого под свой тип нагрузки. В дальнейшем это привело к увеличению сложности приложений как таковых и росту популярности микросервисных архитектур. Среди микросервисов появились, как микросервисы без состояний, так те, что активно используют и хранят состояние сами по себе.

Системы без состояния, относительно просты в реализации. Поэтому мы сфокусируемся на проектировании систем с состоянием и правильной работе с данными.

При этом нас интересуют сервисы, которые хранят и обрабатывают состояние в любом виде: в своей оперативной памяти, на локальном диске или настолько комплексно работают с внешними базами данных, что по сути являются полноценными акторами по работе с состоянием — например, управляют вопросами шардирования, репликации или переносом данных между разными базами данных.

Хранение данных на жестких дисках является одним из наиболее распространенных и старейших способов сохранения информации. Диски обеспечивают долговечное и относительно надежное хранение данных, однако они могут быть подвержены сбоям, износу и другим проблемам, которые могут привести к потере информации.

Оперативная память приложений обеспечивает быстрый доступ к данным во время выполнения программы. Однако, она обладает ограниченным объемом и теряет свое содержимое при выключении питания, что делает ее непригодной для долгосрочного хранения данных без дополнительных ухищрений, вроде записывания данных одновременно на диски для хранения и содержания их в памяти для быстрого доступа.

Специализированные базы данных играют ключевую роль в сфере хранения данных. Они предоставляют удобный интерфейс для организации, поиска и манипуляции данными, а также обеспечивают механизмы для обеспечения их надежности и безопасности. Такие базы данных в свою очередь могут использовать различные методы хранения, включая хранение на дисках, кэширование в оперативной памяти, а также применять репликацию и шардинг для обеспечения высокой доступности и масштабируемости.

Давайте более детально рассмотрим различные аспекты баз данных, которые помогут нам принимать более информированное решение при выборе того или иного решения для своих нужд.

Базы данных различаются по месту хранения:

• В памяти: данные хранятся и обрабатываются непосредственно в оперативной памяти компьютера, что обеспечивает высокую скорость доступа к данным.
• На дисках: данные хранятся на постоянных носителях, таких как жесткие диски или твердотельные накопители, обеспечивая устойчивость и долговечность хранения.
• В другой базе данных: иногда специализированные системы для работы с данными в свою очередь хранят данные в другой базе данных, предоставляя расширенный функционал. Часто местом хранения будет выступать более простая примитивная система, например, S3, а специализированный сервис будет существенно расширять этот функционал. Другой вариант — сочетать несколько систем хранения и получать таким образом расширенный функционал в итоговом сервисе. Например, можно хранить данные в S3, а метаданные в PostgreSQL с целью получения базы данных с новыми свойствами.

По модели данных:

• Реляционные (SQL): данные организованы в виде таблиц, которые связаны между собой ключами. Это наиболее распространенная модель для хранения структурированных данных.
• Документные или объектные: данные хранятся в формате документов или объектов, что позволяет более гибко организовывать информацию.
• Графовые: данные представлены в виде графа, где узлы представляют объекты, а ребра - их отношения. Эта модель хорошо подходит для представления сложных взаимосвязей.
• Иерархические: данные организованы в виде иерархии, где каждый элемент имеет одного родителя и ноль или более детей.

По строгости определения данных:

• Со схемой данных: данные имеют четко определенную структуру и типы данных.
• Без схемы данных: данные могут быть более гибкими и динамическими, что позволяет быстрее адаптироваться к изменяющимся потребностям.

По возможностям индексации:

• Hash-индексы
• B-Tree
• SSTable
• Полнотекстовый (обратный) индекс
• Fuzzy-индексы (неточный поиск)

По возможностям языка запросов:

• Получение значений по ключу
• Поиск и фильтрация
• Запросы с отношениями (SQL)
• Траверс по данным

По локальности данных:

• Строковые: данные хранятся рядом с теми частями приложения, которые их используют, что обеспечивает более быстрый доступ.
• Колоночные: данные хранятся в виде колонок, что обеспечивает более эффективное сжатие и улучшенную производительность при выполнении агрегирующих запросов.

По возможностям масштабирования:

• с возможностью горизонтально масштабироваться
• без такой возможности или существенно ограниченно в такой возможности

По возможности распределенной работы

Тесно связано с возможностями масштабироваться Репликация: Возможность создания копий данных для повышения отказоустойчивости и увеличения производительности чтения. Шардинг: Разделение данных на отдельные фрагменты для распределения нагрузки и увеличения производительности.

Так же некоторые БД имеют возможность по разному работать с данными, организуя горячие и холодные данные.

Транзакционность: Поддержка транзакций для обеспечения целостности данных при одновременном доступе нескольких клиентов.

Автоматическое восстановление после сбоев: Возможность системы восстанавливаться после сбоев или отказов без потери данных.

Шифрование данных: Защита данных с помощью различных методов шифрования для обеспечения конфиденциальности и целостности.

Аудит и журналирование: Ведение записей о действиях пользователей и изменениях данных для обеспечения безопасности и возможности анализа.

SQL базы данных: Реляционные базы данных и язык SQL

SQL (Structured Query Language) является стандартным языком запросов, используемым для работы с реляционными базами данных. Реляционные базы данных организованы в виде набора таблиц, которые содержат строки и столбцы, а доступ к данным осуществляется с помощью SQL запросов.

Особенности SQL баз данных по различным свойствам:

Индексы: SQL базы данных поддерживают различные типы индексов, такие как B-Tree, Hash-индексы и другие, для ускорения выполнения запросов.

Транзакционность: SQL базы данных обеспечивают транзакционную модель, которая гарантирует целостность данных при одновременном доступе нескольких пользователей.

Репликация: Многие SQL базы данных поддерживают механизмы репликации для создания копий данных и повышения отказоустойчивости системы.

Масштабируемость: Однако, с увеличением нагрузки и объема данных, масштабирование SQL баз данных может стать проблемой. Традиционные SQL базы данных имеют свои ограничения в отношении масштабирования и могут столкнуться с проблемами производительности при работе с большими объемами данных и высокими нагрузками.

Важно отметить, что язык SQL и реляционные базы данных не ограничиваются только SQL базами данных. Некоторые NoSQL базы данных также поддерживают SQL-подобные интерфейсы для работы с данными.

Одной из ключевых особенностей реляционных баз данных является поддержка ACID-свойств:

Атомарность (Atomicity): Операции базы данных считаются атомарными, что означает, что они либо полностью выполняются, либо не выполняются вообще. Нет промежуточных состояний, в которых операция может быть выполнена частично.

Согласованность (Consistency): База данных всегда находится в согласованном состоянии после завершения транзакции. Это означает, что данные всегда соответствуют определенным правилам целостности и ограничениям. Примеры правил целостности могут включать в себя:

Уникальность значений в определенной колонке (например, уникальный идентификатор пользователя в таблице пользователей). Ссылочная целостность, где значения внешних ключей должны ссылаться на существующие значения в связанных таблицах.

Изолированность (Isolation): Транзакции выполняются изолированно друг от друга, что означает, что результаты одной транзакции не видны другим транзакциям до ее завершения. Это обеспечивает предсказуемое поведение при параллельном выполнении нескольких транзакций.

Долговечность (Durability): После успешного завершения транзакции изменения, внесенные в базу данных, остаются сохраненными даже в случае сбоя системы или отказа.

Хотя ACID-свойства обеспечивают надежность и целостность данных, они могут снижать производительность при высоких нагрузках из-за необходимости обеспечения изоляции и долговечности транзакций.

Часто в распределенных системах возникает необходимость в согласовании изменений, внесенных разными участниками системы, чтобы гарантировать согласованность данных и избежать конфликтов. Это может быть особенно актуально в случае работы с небольшими данными, такими как конфигурационные файлы, настройки или счетчики, к которым применяются особые требования по целостности и консистентности.

Например, в распределенной системе могут использоваться технологии репликации данных, кэширования или шардинга, чтобы обеспечить высокую доступность и масштабируемость. При этом важно, чтобы все изменения, вносимые в данные в различных узлах системы, были согласованы и соответствовали определенным правилам.

Для решения этой проблемы могут применяться различные методы, такие как использование распределенных транзакций, протоколов согласования или алгоритмов репликации данных с поддержкой конфликтов.

Таким образом, вопрос согласования работы различных частей распределенной системы также является работой с данными и требует особого внимания к целостности и консистентности данных.

Проблемы с распределенными SQL базами данных

Распределенные SQL базы данных, предназначенные для обработки больших объемов данных и высокой производительности, часто сталкиваются с рядом сложностей:

Сложность масштабирования: При увеличении нагрузки на систему и объема данных может возникнуть необходимость в горизонтальном масштабировании. Однако, в случае SQL баз данных, это может быть сложно в реализации из-за требований ACID и необходимости обеспечения целостности данных при распределении на несколько узлов.

Проблемы согласованности данных: В распределенных системах, где данные хранятся на разных узлах, возникает сложность с согласованием данных между узлами. Это может привести к конфликтам данных, потере целостности и непредсказуемому поведению системы.

Производительность и задержки: Коммуникация между узлами распределенной системы может привести к задержкам при выполнении запросов. Это особенно критично для транзакционных операций, которые требуют быстрого доступа к данным и минимальной задержки.

Сложность управления: Управление распределенной SQL базой данных может быть сложным из-за необходимости координации между различными узлами, обеспечения репликации данных и управления конфигурацией системы.

Большие затраты на инфраструктуру: Распределенные SQL базы данных часто требуют дорогостоящей инфраструктуры для обеспечения высокой доступности, отказоустойчивости и производительности.

Эти проблемы делают разработку, настройку и обслуживание распределенных SQL баз данных сложной задачей, требующей глубоких знаний в области баз данных, сетевых технологий и алгоритмов распределенных систем.